TESTING PLAYBOOK

ABC Membership & Dues — Testing Playbook

Your complete guide to understanding the business, testing strategies, and regression coverage

The Business

Before you can test this system, you need to understand the business it serves. Everything in the M&D module exists because of how ABC's membership model works in the real world.

🏗️ What ABC Actually Is

ABC (Associated Builders and Contractors) is a national trade association for the construction industry. Think of it like a franchise model: there's one national organization, but the actual member relationships happen through independent local Chapters spread across the country.

The most important thing to understand is that membership is corporate, not individual. A construction company joins ABC — not a person. The company joins through one local Chapter (their "Primary Chapter"), but can also belong to additional Chapters if they work in multiple regions.

This is the root of a lot of the system's complexity. One company, potentially multiple chapters, but National dues only get paid once. The system has to track all of that.

Why this matters for QA
Every test scenario involving a member company needs to account for this Primary Chapter relationship. When you see bugs around "duplicate invoices" or "wrong National dues amount," it's usually because the system lost track of which chapter is the Primary.

💰 How Money Flows Through the System

This is the single most important concept to internalize. When a member company pays their dues, that payment doesn't just sit with the Chapter. It gets split and forwarded to multiple parties. Here's how:

Member Company
Pays one combined invoice
Chapter
Keeps Chapter Dues, forwards the rest
ABC National
Receives National Dues + FEA + TCEF via Wells Fargo

The member sees one invoice. But behind the scenes, that invoice is broken into separate buckets: Chapter Dues, State Dues (if applicable), National Dues, and voluntary contributions like FEA, TCEF, and PAC. Each bucket has different rules about who controls the amount and where the money goes.

The critical rule: National dues amounts are locked. Chapters can set their own Chapter dues, but they cannot change what National charges. This is enforced at the system level — it's not just a business rule, it's a hard constraint in the software.

Why this matters for QA
Every invoice test needs to verify that the National portion is untouchable by chapter staff. If you can edit National dues on a New or Renewal invoice through the UI, that's a critical bug. The only way to adjust National amounts is through an Adjusted invoice type.

📊 Dues Categories: Why Members Pay Different Amounts

Not every member pays the same amount. ABC uses Dues Categories to tier its pricing based on company type (contractor, associate, supplier) and annual revenue. A large general contractor with $50M in revenue pays significantly more than a small specialty sub.

Categories are grouped into Schedules. Think of a Schedule as a pricing sheet for a given year — it lists every category and what each one costs. A Chapter can have multiple schedules in the same year (for example, one for urban members and one for rural).

Each category breaks down into the same buckets as the invoice: Chapter $, State $, Other $, National $, and Total $. When a member is assigned to a category, their invoice amounts are driven by that category's pricing.

Locked by National
National $ amounts on each category are set by ABC National. Chapters cannot change them. If National updates their amounts, chapters must explicitly "Apply National Dues Change."
Set by Chapter
Chapter $, State $, and Other $ are set by the chapter. They control their own pricing within the schedule, giving flexibility for regional differences.
Why this matters for QA
When testing invoice amounts, trace them back to the member's category. If the numbers on an invoice don't match the category pricing, something went wrong during invoice creation. Also test what happens when National changes their amounts mid-year — existing invoices should NOT retroactively update.

📅 The Membership Timeline: First Year Is Special

Most members renew on a standard January–December calendar year. But the first couple of years for a new member are handled differently, and this is where a lot of the invoice math complexity comes from.

Year 1 — Full 12 Months
Starts from the month they join. If they join in September, Year 1 runs Sep through Aug of the next year. They pay full annual dues.
Year 2 — Prorated
Covers the remaining months of the calendar year after Year 1 ends. The formula: (Annual Dues ÷ 12) × months remaining. This is where the proration logic lives.
Year 3+ — Standard
Normal Jan–Dec cycle. Same as every other renewing member. No special handling needed.

There's also the 15-for-12 program: if a company joins in October, November, or December, they can pay for 12 months and get 15 months of membership. The system creates a $0 renewal invoice for Year 2 (with full amounts as Original and full amounts as Credits), marked as paid on the same date and flagged as 15-for-12.

Why this matters for QA
The proration formula is one of the most error-prone areas. The formula is: Total = (Dues ÷ 12) × (12 - month_joined + 1). Credit = Original - Total. Make sure you never see it inverted (Credit and Total swapped). For 15-for-12, verify the $0 invoice is auto-created and properly flagged — this was a previous defect area. AMENDED · ABC-2842

👥 Who Uses This System (and Why It Matters)

There are four groups of people who interact with the M&D module, and understanding their perspective helps you write better tests:

Chapter Staff are the primary users. They do everything: set up the dues year, run batch invoicing, create individual invoices, record payments, and submit monthly data to National. Most of the system's UI is built for them.

ABC National Staff oversees all chapters. They define National dues amounts, review monthly chapter submissions through a Processing Queue, approve or reject them, and publish approved data to Wells Fargo for payment processing. They have a different navigation and see data across all chapters.

Member Companies interact through the portal. They see their invoices, pay online (credit card or ACH), and view payment history. They have a much simpler experience — they don't see the complexity behind their invoice.

Member Portal Admins (Level 3) are the specific contacts within a member company who have permission to view and pay invoices in the portal. Not every company contact can do this.

Why this matters for QA
Always consider which user role you're testing as. A bug that only affects National staff might never be caught if you only test as Chapter staff. And portal tests need to account for the two access paths: the no-login payment link (with reCAPTCHA and lockout) and the authenticated portal experience.

How It Works

Detailed system workflows showing invoicing, payments, national reporting, and critical edge cases.

Annual Cycle

How a chapter's dues year unfolds — from setup in the summer through batch invoicing in the fall to monthly reporting all year long.

⚙️ Dues Year Setup: Laying the Foundation

Before a single invoice can be created, Chapter Staff must configure the dues year. This is a critical setup phase, typically done in summer, where the chapter defines all the financial parameters that will drive invoices for the next 12 months. Think of it as building the pricing engine.

Setup includes: Dues Categories (the membership tiers and their dollar amounts), Schedules (groupings of categories), Additional Line Items (voluntary contributions like FEA and TCEF), Discount-If-Paid-By windows (early payment incentives), and Invoice Memos (custom messages that appear on invoices). The system supports bulk copy from the previous year to save time.

A unique part of the setup is the National Dues Alignment screen. When ABC National changes its category structure mid-year, chapters must map their existing categories to the new National structure. This ensures invoice amounts stay correct and synchronized across the organization.

Also during setup: Percent Not Deductible calculations for tax purposes. Chapters enter the percentage (provided by National), and this auto-generates a tax disclaimer line item on every invoice for that year.

Why this matters for QA
Test the bulk copy feature thoroughly — if categories don't copy correctly, the chapter will either have to manually re-enter everything or their invoices will have wrong amounts. Also verify that when National updates dues amounts, the "Apply National Dues Change" split-button works correctly: one option increases the total, the other reduces the chapter portion while keeping total the same. If either branch breaks, all invoices created after will have wrong National amounts. JIRA · ABC-1601 JIRA · ABC-1602

📋 Batch Invoicing: The Annual Push

Once setup is complete, typically in September or October, Chapter Staff runs the annual batch invoicing process. This is a four-step wizard that creates renewal invoices for all members at once. The system handles the heavy lifting — calculating prorated amounts, applying discounts, formatting invoices for print or email, and generating the PDF files in bulk.

Step 0 begins with audits. The system runs 11 audits (6 focused on members, 5 on invoices) to catch common data issues: members with invalid categories, chapter-only members with broken cross-references, members who should be prorated, and duplicate invoices. Importantly, these audits are NOT required to pass. Chapter Staff can review errors and decide whether to fix them or continue anyway. This is an audit tool, not a blocker.

Step 1 is record selection. Chapter Staff chooses which members to include: active ABC members with paid prior-year invoices who don't already have a current-year invoice. The system shows the full list, lets staff search and deselect anyone who shouldn't be invoiced, and compares the list to last year to highlight changes.

Step 2 is customization. This is where the magic happens: staff choose invoice layout options (address type, contact name, category sorting), select which additional line items and discount windows apply, pick invoice memos, and decide which categories print on the invoice. They can also create or save Preference Sets — named groupings of memos, discounts, and line items that can be reused in future batch runs. This section is powerful and detailed, designed to give chapters full control over invoice appearance.

Step 3 commits everything to the database. The system writes all invoice records, assigns invoice numbers, and deletes the temporary batch files. Once this step runs, invoices appear on the Dues Landing Screen and are ready to be emailed or mailed to members.

Why this matters for QA
The batch process is one of the most complex features in M&D. Key bugs to watch for: (1) Audits incorrectly excluding or including members. (2) Step 1 record selection logic — make sure members with no prior paid invoices are excluded even if they're marked Active. (3) Step 2 customization — verify that selecting a Discount actually applies the discount amount to the invoice, and that memos render correctly on the PDF. (4) Step 3 — ensure invoice numbers are assigned in the correct format (YY-COMPANYID + Type) and that no duplicate numbers are generated. Test edge cases like members who should be prorated (joined mid-year, now in Year 2) and 15-for-12 eligibility (joined Oct/Nov/Dec). AMENDED · ABC-2057

📊 Day-to-Day Invoice Management: The Year Continues

After batch invoicing, Chapter Staff still has work to do. Individual members join, need invoices created ad-hoc. Categories change. Companies need adjusted invoices. Payments come in and need to be recorded. The Dues Landing Screen is where all this happens.

The landing screen shows all invoices with filters: by status (Open, Paid, Dropped), type (New, Renewal, Adjusted), company name, date paid, and more. Staff can drill into any invoice, view its history, see what was paid and when. They can edit open invoices (changing addresses, memos) and mark invoices as Paid when members send checks. For partial payments, they record the amount paid and select which dues buckets (National, Chapter, State, Other) the payment applies to. The system generates a new adjusted invoice for the remaining balance.

One key rule: Paid invoices are now editable by Chapter Staff. This was changed from the original spec. Staff can change the category on a paid invoice, and the system creates an adjusted invoice showing the difference between what was paid and what should have been paid.

Why this matters for QA
Test the invoice creation flow thoroughly. When staff creates a New invoice for a member, validate that the system correctly rejects creating another New or Renewal for the same member/year. Test partial payments: the minimum must be at least the National dues amount. If staff tries to partially pay the National portion alone, the system should accept it (and create an adjusted invoice for the chapter/state balance). Also verify that National dues cannot be partially paid as part of a mixed payment unless the payment amount exactly equals the National dues (it's either all National or zero). Paid invoices being editable is new — make sure category changes on paid invoices create adjusted invoices and don't break the original invoice record. AMENDED · ABC-2578

📤 Monthly Reporting: The Heartbeat

Every month, a formal process happens. Chapter Staff gathers all paid invoices for the month, reviews them against configured audits, and submits the data to ABC National. National then reviews, approves, and publishes the data to Wells Fargo for payment processing. This is the critical financial reporting cycle.

On the Chapter side, Staff access a Monthly Dues screen for the selected month/year. They see all paid invoices, line alert statuses (OK, Information, Warning, Error based on audit results), and options to submit to National and generate reports (Dues Statement PDF, Dues Detail by Member, FEA, TCEF). Once they click "Submit to National," the data locks and moves to National's queue.

On the National side, there's a Processing Queue showing all chapters' submissions sorted by status (Open, Submitted, Under Review, Approved, Published). National Staff reviews each chapter's data, can request sign-off from Chapter Staff (via automated email), approves when satisfied, and then publishes invoices to Wells Fargo. Published data is locked and cannot be changed without National explicitly reopening the month.

Why this matters for QA
The monthly reporting process involves state transitions and permissions. Test that Chapter Staff can only see and submit their own chapter's data, not other chapters. Verify that once a chapter submits, their data is locked (they can't make changes without National sending it back). National should be able to approve without requiring Chapter Sign-Off — the sign-off is optional, not mandatory. When National publishes to Wells Fargo, verify the data is truly locked afterward. For closed months: National can reopen them to make corrections, but this is manual and only at their discretion — there's no fixed window. AMENDED · ABC-2767 AMENDED · ABC-2780

Invoicing

The invoice is the core document in this system. Understanding invoice types, creation rules, and payment logic is essential to testing the module.

📄 Invoice Types: Three Flavors, Different Rules

The system distinguishes three invoice types, each serving a different purpose. New (N) invoices are created for members in their first year of membership. A member can only have one New invoice per year. Renewal (R) invoices are annual invoices for existing members who have paid a prior-year invoice. Like New invoices, only one Renewal per member per year. Adjusted (A) invoices are corrections or modifications to existing invoices. A member can have multiple Adjusted invoices in the same year.

Invoice numbers reflect this: YY-COMPANYID + Type. So a 2025 invoice for Company ID 12345 might be 25-12345N (New), 25-12345R (Renewal), or 25-12345A1, 25-12345A2, 25-12345A3 (Adjusted sequence). The original invoice number (N or R) is stored on each Adjusted invoice so staff always knows what they're adjusting.

The key differences: New and Renewal invoices have locked original amounts. Staff cannot change what the National portion is, what the Chapter portion is, or what the State portion is. Those amounts come from the member's dues category and are read-only. Only Adjusted invoices allow credit changes. Adjusted invoices also have a special feature: they're the only way to credit National dues (on a New or Renewal, National credit is forbidden except through an Adjusted invoice).

Why this matters for QA
Test the validation on invoice creation. If staff tries to create a second New or Renewal for the same member/year, the system should reject it. Test that New invoices can only be created if the member's join date falls within the invoice year. Test that Renewal invoices require a paid prior-year invoice. For Adjusted invoices, verify that only the credit totals are editable, not the original amounts. And crucially, test that National dues can only be credited to zero (full credit) or full amount (no credit) — partial credits are not allowed on the National line.

🧮 The Proration Math: Year 2 Gets Special Treatment

A member who joins in their first calendar year (say, September) gets a full 12 months of membership. But then in Year 2, they're on the calendar year cycle like everyone else. Because they've already paid for September through August, Year 2 only covers September through December — 4 months. The system pro-rates their dues down to reflect this shorter billing period.

The formula is: Total = (Annual Dues / 12) × (12 - month_joined + 1). The credit shows the difference between full-year Original and the prorated Total. So if a member joins in September and Year 2 Annual Dues is $1200, the calculation is: ($1200 / 12) × (12 - 9 + 1) = $100 × 4 = $400. Original is $1200, Total owed is $400, Credit is $800.

The system auto-calculates prorated amounts when creating a Year 2 Renewal for an eligible member. It marks the invoice as Prorated so staff knows to expect different amounts. This calculation applies to the Chapter, State, and National portions separately.

Why this matters for QA
The proration formula is a high-bug-density area. The most common mistake: inverting the formula so Credit is calculated as (12 - month) instead of (12 - month + 1), off by one. Create test data for members who joined in different months (early, mid-year, late) and verify the proration. Check a member who joined in September — they should be prorated. Check a member who joined in February — they should also be prorated (4 months remaining). Check a member who joined in January — they should NOT be prorated (the Year 2 is already Jan-Dec). And verify that the same proration applies equally to all dues buckets: if Chapter is prorated from $600 to $200, State should also scale proportionally. AMENDED · ABC-2842

💳 Invoice Payment & Category Changes

Invoices can be paid at creation time or marked as paid later when the check arrives. The system validates that chapter-only members have valid cross-references at payment time (if the XREF is broken, the invoice can't be paid, except in the partial pay case). Once paid, the payment date, amount, and payment method (check, credit card, ACH) are recorded on the invoice.

One scenario that comes up frequently: a member is invoiced under one category, but before payment their company growth means they should be in a higher category. Chapter Staff can change the category on an unpaid invoice, and the system recalculates all amounts based on the new category. If the invoice is already paid, changing the category triggers the creation of an Adjusted invoice showing the difference between what they paid and what they owed in the new category.

Partial payments are also supported. Staff enters the amount paid and selects which dues buckets the payment applies to. The minimum partial payment must be at least the National dues amount. The system generates a new Adjusted invoice for the remaining balance. National dues themselves cannot be split — you either pay the full National amount, or $0, but not $500 of $1000.

Why this matters for QA
Test partial payments carefully. The minimum check should enforce: you can't pay less than National dues (unless National is $0). Also, when staff applies a partial payment to specific buckets, verify that the math is correct. If an invoice has Chapter $500, State $200, National $300 (Total $1000), and staff pays $300 toward National only, the adjusted invoice should show National $0 remaining, with Chapter $500 and State $200 still due. Category changes on paid invoices should create Adjusted invoices, not modify the original. And unpaid invoices with category changes should update the amounts inline without creating adjusted invoices. AMENDED · ABC-2078

🔗 Discounts, Line Items, and Invoice Customization

Every invoice can include additional line items (FEA, TCEF, PAC, chapter-defined items) and can be subject to discounts. Discounts are configured with actual date ranges (From/To dates), not relative to invoice date. So a discount might be "10% off if paid by November 15" — the system checks the payment date against that fixed window. Chapters can define multiple discount windows in the same year (e.g., 10% by November, 5% by December).

Discounts can be applied to the total invoice, or specifically to chapter/state/other dollars (National dollars never get discounted, per ABC's rules). Percentage discounts and flat-dollar discounts are both supported. Chapters can also choose to ignore prorate credits when applying discounts (useful for special promotions).

Additional line items can be per-invoice flat amounts (e.g., "$25 PAC contribution") or percentages (e.g., "5% technology fee"). Items flagged as "voluntary" allow members to opt in or opt out on the invoice. Items flagged as "mandatory" are always included.

Why this matters for QA
Test discount application thoroughly. Create an invoice with a 10% discount window of Nov 1–15. Pay it on Nov 10 — discount should apply. Pay it on Nov 20 — discount should not apply. Pay it on Oct 25 — discount should not apply. Verify that the discount amount is calculated correctly from the base amount (if it's 10% of National+Chapter, make sure State isn't included if not configured). Test percentage-based additional line items: if a member's invoice is $1000 and they have a 5% tech fee, it should add $50, not a fixed amount. And for voluntary contributions on invoices, make sure members see them with opt-in/opt-out controls on the portal, and that their choices are recorded.

Getting Paid

From the member's perspective, paying their dues should be simple. From the system's perspective, handling payment from multiple channels and recording it correctly is complex.

🔐 The No-Login Payment Link: Convenience Without Account Access

When Chapter Staff send a dues invoice via email, the email includes a link that members can click to pay without logging into the portal. This is the most frictionless payment path. The member clicks the link, sees their invoice, and pays immediately with no passwords or account setup required.

This convenience comes with security measures. The link is single-use and tied to a specific invoice. When a member (or anyone) attempts to use the link, they must complete a reCAPTCHA. If they fail payment 5 times, they're locked out for 30 minutes. These measures prevent brute-force attacks and bot abuse. If members are already logged into their portal account, the reCAPTCHA and lockout don't apply — they're bypassed for authenticated users.

Once the member arrives at the payment screen, they see the invoice details (member info, invoice number, amount due), see any voluntary contributions with checkboxes to opt in/out, and choose a payment method: credit card or ACH. The system passes the transaction details to the configured payment gateway (Authorize.net or similar), stores the transaction ID and timestamp, but never stores the credit card number itself.

Why this matters for QA
Test the no-login link thoroughly. Verify that the link is invoice-specific (paying through a link for Invoice A shouldn't somehow mark Invoice B as paid). Test the reCAPTCHA integration — the widget should appear and validate correctly. Test the 5-failure lockout — fail 4 times and retry, succeed on the 5th; fail a 5th time and confirm the 30-minute lockout message appears. Test that credit card numbers are not logged anywhere (check logs, database, email receipts). And test that voluntary contributions display with the correct opt-in/opt-out defaults and that member selections are recorded.

🏪 The Member Portal: Full Control and History

Members who have a portal account can access their invoices directly. The portal shows two tabs: Open Invoices (unpaid) and Invoice History (paid invoices). The Open Invoices tab shows all current-year invoices with filters by type (dues), allows members to view payment details, print invoices, and pay. The Invoice History tab shows past invoices with date-range filters (30/60/90 days, 6 months, 1 year) and shows payment date, payment method, and check number (if applicable).

Portal access is role-based. Not every employee at a member company can see invoices. Only Member Portal Admins (Level 3) have access. This is a company-specific permission, not chapter-wide. The portal admins for Company A can see Company A's invoices; they cannot see Company B's invoices.

Portal payment works the same way as the no-login link: credit card or ACH, same gateway integration, same transaction recording. The key difference is that authenticated users skip the reCAPTCHA and lockout measures — the portal login itself is the security layer.

Why this matters for QA
Test portal role separation carefully. Create a non-admin contact for a member company and verify they cannot access the portal. Create a Level 3 contact and verify they can only see their own company's invoices, not other companies'. Test the date-range filters on the history tab — make sure "Last 30 days" correctly filters to invoices paid in the last 30 days, not created 30 days ago. And verify that portal users see the same volunteer contribution opt-in/opt-out controls as no-login users, but without the reCAPTCHA friction. AMENDED · ABC-2166

Post-Payment: What Happens After Money Lands

When a payment succeeds — whether through the no-login link, the portal, or a check that chapter staff manually records — a series of automated actions happen. The invoice status changes from Open to Paid. The payment date, amount, method (online CC, online ACH, check), and gateway transaction ID are recorded on the invoice. The member's contact record is updated: their dues history is appended with the payment, their "Last Year Paid" field is updated. Voluntary contribution selections are recorded per invoice.

Email notifications fire automatically. Chapter Staff receive a payment confirmation email (configured with CC/BCC recipients per chapter). The paying member receives a confirmation email to the address they used for login (or the address on the no-login link). If payment fails at the gateway, the chapter is notified of the failure so they can follow up with the member.

For members in their first year, there's an additional automation: the system checks 15-for-12 eligibility (member joined Oct/Nov/Dec). If eligible, after the first-year invoice is paid, the system can optionally create a $0 renewal invoice for Year 2 (full amounts as Original, full amounts as Credits, marked as paid, flagged as 15-for-12). This gives the member 15 months of membership for paying 12 months of dues.

Why this matters for QA
Test the post-payment flow end-to-end. Verify that invoice status transitions to Paid immediately. Check that payment confirmations are sent to the correct email addresses (especially important for no-login payments where the member's email came from the invoice record, not a portal account). Test 15-for-12 eligibility logic: members who joined in Oct/Nov/Dec should get the $0 Year 2 invoice after Year 1 payment; members who joined other months should not. Verify the $0 invoice is marked as both paid and flagged as 15-for-12 so it's not mistaken for an uncollected invoice. Also verify that if a member makes a partial payment, only the partial amount is recorded (not the full invoice amount), and the contact record reflects the remaining balance due. AMENDED · ABC-2879

🚫 The Portal Payment Constraint: Full or Nothing

Members using the portal or no-login link cannot make partial payments. They must pay the invoice in full. This is a hard constraint, not a business preference. The payment screen doesn't offer a "payment amount" field — it shows "Amount Due: $X" and the payment is for that full amount.

Partial payments are only available to Chapter Staff via the Day-to-Day Invoice Management screen. This is intentional: partial payments are an administrative tool, not a self-service member feature. Members pay in full or don't pay. Chapter Staff, if needed for business reasons, can record smaller payments and generate adjusted invoices for the remainder.

Why this matters for QA
Verify that the portal and no-login payment flows enforce full-amount-only payment. If the invoice is $1000, the payment must be $1000, not $500. Test that the amount due is read-only and cannot be modified by the user. And conversely, verify that Chapter Staff on the Day-to-Day screen CAN enter a partial amount (respecting the minimum threshold of National dues) and that adjusted invoices are created for the balance.

National Reporting

Every month, chapters and National play a coordinated dance. Chapters submit their paid invoices, National reviews and approves, and the data flows to Wells Fargo for financial processing.

📅 The Monthly Dues Report: Chapter Side

Around the 20th of each month (date set by National), Chapter Staff log in and navigate to their Monthly Dues screen. They select the month/year they want to report on, and the system shows all paid invoices for that period. The table displays each invoice with its line alert status (OK, Information, Warning, or Error based on pre-configured audits), invoice details, and dollar amounts broken down by category type (National, State, Chapter, voluntary contributions).

Before submitting, Chapter Staff can run reports: Monthly Dues Statement (PDF showing summary), Dues Detail by Member (PDF with full breakdown), and separate reports for FEA and TCEF contributions. These are available at any point, not just before submission. Chapters also see Year-to-Date totals, helping them track progress toward annual goals.

Once satisfied with their data, Chapter Staff click "Submit to National." The submission is a deliberate, conscious action, not automatic. Upon submission, the chapter's data locks — they cannot make changes without National sending it back. The data moves to National's queue with status "Submitted."

Why this matters for QA
Test the audits that generate line-alert statuses. These audits should flag issues like invalid member types, non-paying members, invalid categories, and broken chapter-only cross-references. Verify that alert statuses display correctly (OK when no issues, Error when significant problems). Test that submission locks the month — after submission, the "Submit to National" button should be disabled and fields should be read-only. And verify that reports generate correctly with accurate totals and formatting. AMENDED · ABC-2598

🔍 The National Processing Queue: The Heartbeat

When a chapter submits, their data enters National's queue. National Staff access the Processing Queue, which shows all chapters with status counts (Open, Submitted, Under Review, Approved, Published). The queue is a table with columns for each chapter, submission date, locked status, and action buttons. National can update status per chapter, add notes (these don't carry over month-to-month), and request sign-off from the chapter contact.

The status flow is: Open (no submission yet) → Submitted (chapter sent data) → Under Review (National is examining) → Approved (National is satisfied) → Published (sent to Wells Fargo). At each step, National can drill into a chapter to see their invoice details and line alert statuses. National can also exclude specific member invoices from processing (useful if there's a data problem with one member but the rest of the chapter is fine).

One important note: National Sign-Off is optional, not required. National can approve and move to publish without requesting or receiving sign-off from the chapter. The sign-off option exists for additional confirmation, but it's not a gating factor.

Once National publishes a month to Wells Fargo, that data is locked. Changes to already-published months require National to explicitly reopen the month, a manual and deliberate action.

Why this matters for QA
Test the status transitions in the queue. National should be able to move a chapter from Submitted directly to Approved without an Under Review step. Verify that Publishing to Wells Fargo is a separate, explicit action with a confirmation warning if the month has already been published. Test the Exclude Invoices feature — National should be able to select one or more members and exclude them, and those invoices should not be processed/published. And verify that Approved chapters can be reverted to earlier states if issues are discovered. AMENDED · ABC-2850

🔄 Corrections and Closed Months: When Mistakes Happen

Mistakes happen. A member type was recorded wrong, an invoice shouldn't have been included, or the amounts were calculated incorrectly. When this happens in a past month that's already been submitted to National or published to Wells Fargo, National can reopen the month for corrections.

There's no fixed window for reopening. National has discretion — they can reopen a month immediately, days later, or months later if needed. When a month is reopened, Chapter Staff can make corrections (change member types, remove invoices, adjust payment amounts), and then resubmit. Each resubmission creates a new version, and National can toggle between versions to see what changed.

Financial implications: if reopening a month changes the amount owed to National, that difference is handled through adjusted invoices in future months (no refunds to chapters, no negative invoices). If a chapter previously underpaid, they submit the difference in the next month's submission. If National overpaid a chapter, the chapter gets an adjusted invoice in a future month to pay it back.

Why this matters for QA
Test reopening a closed month thoroughly. Verify that reopening removes the "locked" status and allows editing. Verify that resubmission after correction increments the version number. Test that when a correction changes the amount owed, the system correctly calculates the difference and documents it as an adjusted invoice (or reduces next month's payment). Also test that National's Wells Fargo publishing doesn't automatically update for months already sent — if National republishes after a correction, that's an explicit action, not automatic. And verify that the version history is preserved so auditors can see what was corrected and when. AMENDED · ABC-2594 AMENDED · ABC-2595

📊 National Reports: The Big Picture

Beyond the month-to-month processing queue, National Staff have access to analytical reports. The Dues Payments vs ABC Load File report identifies discrepancies between what chapters report as paid and what National's master data says should be paid. The SPM Dollars Entry screen records payment amounts by month for New, Renewal, and Adjusted invoices, plus Cloud Fees and other contributions, and ties to Wells Fargo actual payments. Out of Balance reports flag chapters where invoiced amounts don't match collected amounts across various categories (dues, cloud fees, FEA, TCEF).

These reports are auditing tools, used by National to ensure data integrity and catch misreporting at the chapter level.

Why this matters for QA
If you're testing these advanced reporting features, focus on data accuracy. Load test data with intentional discrepancies (chapter reports $10K paid but only $8K in Wells Fargo records) and verify the discrepancy reports flag it correctly. Verify that SPM calculations only include New and Renewal invoices, not Adjusted (since Adjusted are corrections, not new revenue). AMENDED · ABC-2593 AMENDED · ABC-2599

Edge Cases & Special Scenarios

The situations that don't fit the standard flow. These are the cases that break assumptions and are high-bug-density testing areas.

🗂️ Chapter-Only Members: The XREF Complexity

Most members join one chapter (their Primary Chapter) and pay National dues through that chapter. But some members belong to multiple chapters. When a company belongs to Chapter A (primary) and also Chapter B (secondary), Chapter B can invoice the member for Chapter B dues, but not National dues. Chapter B's invoice includes Chapter $ and State $ (if applicable), but the National $ line is $0.

Internally, this relationship is tracked via a cross-reference (XREF): Chapter B's invoice record points to the member record in Chapter A's system, indicating "this is a chapter-only member, and their national home is Chapter A." The system validates this cross-reference at payment time. If the XREF is broken or missing, the invoice cannot be paid (except in the partial-pay case, where staff can override).

This creates a class of defects: broken XREFs, missing XREF lookups, or XREF validation that incorrectly blocks legitimate payments. It's a high-bug area because the relationship is complex and the error messages are often confusing to chapter staff.

Why this matters for QA
Create test data with chapter-only members. Verify that the XREF lookup works correctly when creating invoices. Test payment: if XREF is valid, payment should succeed. If XREF is broken, payment should be rejected with a clear error message. Also test batch invoicing — the audits should flag invalid XREF records so chapter staff can see the problem before batch creates hundreds of unpayable invoices. AMENDED · ABC-2578 AMENDED · ABC-2607

⚠️ Start-Up Contractor: A Removed Feature

The Start-Up Contractor feature has been completely removed from the system as of ABC-2181. This was a 24-month discounted-rate program for new contractors, but it is no longer used. All references to it have been stripped from the UI (Dues Year Setup, batch invoicing, batch audits). Historical data may still exist in the database, but the business rules no longer apply.

If you encounter Start-Up Contractor references in old documentation or legacy code, ignore them. The feature will not be developed or fixed.

Why this matters for QA
Don't write test cases for Start-Up Contractor features. If historical data contains Start-Up Contractors, they should be treated as regular members now. And verify that any old UI fields related to Start-Up Contractor (category selection, discount calculations) have actually been removed and don't appear in the current build. AMENDED · ABC-2181

📐 Proration Edge Cases: Join Month Matters

Proration happens only in Year 2 for members who joined between February and December. A member who joins in January is already aligned with the calendar year, so no proration happens — they just renew normally Jan-Dec. A member who joins in December gets a full Year 1 (Dec through Nov), then a Year 2 proration for only 1 month (December). The calculation still applies: (Dues / 12) × (12 - 12 + 1) = (Dues / 12) × 1 = Dues/12.

Proration applies to all dues buckets proportionally. If Chapter dues are $600 of $1200 total, and the invoice is prorated to 50%, both Chapter and total scale to $300. The ratio is preserved.

Why this matters for QA
Create members who joined in different months and verify proration correctness. Jan joiners should not prorate. Dec joiners should prorate heavily (11/12 of the year). Feb joiners should prorate moderately (10/12 of the year). And for each, manually calculate what the Year 2 amount should be and verify the system matches. Also test that the credit calculation is correct: Credit = Original - Prorated Total, not inverted. AMENDED · ABC-2767

💰 The 15-for-12 Program: The $0 Invoice

Members who join in October, November, or December are eligible for 15-for-12: they pay for 12 months of membership but get 15 months. The system implements this by creating a $0 renewal invoice for Year 2. The Original amounts are full-year amounts. The Credit amounts are also full-year amounts. The Total owed is $0. The invoice is marked as Paid on the same date as the Year 1 invoice, and it's flagged as "15-for-12" so staff knows it's not an uncollected invoice.

This feature has been a source of defects in the past. The $0 invoice must be created correctly, marked as paid, and properly flagged. If any of these fail, Year 2 appears to have no invoice, which can cause issues in batch invoicing and monthly reporting.

Why this matters for QA
Test 15-for-12 eligibility and creation. Create members who joined Oct, Nov, Dec and verify that after Year 1 invoice payment, the system prompts or auto-creates a $0 Year 2 invoice. Verify the $0 invoice is marked as paid (not open). Verify it's flagged as 15-for-12. Then in batch invoicing for Year 3, verify that the 15-for-12 renewal is excluded from batch (it already got Year 2 coverage) and doesn't create a double invoice. And test members who joined other months — they should NOT get the $0 Year 2 invoice. AMENDED · ABC-2602

👤 Life Members: Individual and Rare

Most membership is company-based (dues categories, tiers, revenue-based pricing). But a small subset of members are Life Members — individuals afforded lifetime membership status in recognition of substantial past contributions to ABC. They don't fit the standard company-dues-category model. Life Members are tracked in the system separately and have special handling during batch invoicing and reporting.

Why this matters for QA
Life Members are rare, so bugs often slip through. If you can access test data with Life Members, verify that batch invoicing correctly excludes them (they shouldn't be invoiced repeatedly). Also verify they show up in reports correctly and don't break monthly reporting audits. AMENDED · ABC-2725

🗄️ Non-CHAD2 Chapters: File Imports Instead of Real-Time Data

Not all ABC chapters use CHAD2 as their member database. Some chapters use legacy systems or external AMS software. For these chapters, the M&D module supports monthly file imports. Chapter staff upload a Bridge file (from a third-party vendor) or a Load file (from legacy CHAD), the system parses and transforms the data, and treats it as if members and invoices were created directly in CHAD2.

The import process transforms flat-file data into CHAD2's relational structure. If the import has structural errors, the system communicates what's wrong. After a successful import, the chapter proceeds with the same monthly reporting workflow as CHAD2 chapters.

Why this matters for QA
Non-CHAD2 imports are a lower-frequency code path (fewer chapters use them), so bugs are less likely to be caught in production. If you're testing imports, create malformed files and verify the system gives clear error messages. Test that after a successful import, data appears correctly on the Monthly Dues screen and can be submitted to National without issues. Also verify that the import process doesn't corrupt existing data (chapters that run imports monthly should have all prior data intact). AMENDED · ABC-2370

💵 PAC and Voluntary Contributions: Opting In and Out

PAC (Political Action Committee) contributions and FEA/TCEF contributions are additional line items on invoices. Some are mandatory (always invoiced), others are voluntary (members choose to opt in or opt out on the invoice or portal). The system tracks member selections and records them per invoice. Voluntary items default to "opt in" status, but members can uncheck them to exclude from payment.

Why this matters for QA
Test that voluntary line items appear on invoices and the portal with clear opt-in/opt-out checkboxes. Test that member selections are honored (if they opt out of FEA, it shouldn't be invoiced). Test that selections are recorded in the payment record so there's an audit trail of what the member chose. And test that mandatory contributions cannot be opted out — they appear on the invoice with no checkbox.

Glossary

Quick reference for terms you'll encounter throughout the ABC Membership & Dues module. Bookmark this section.

Term Definition
Chapter Independent local organization chartered by ABC National. The direct interface with member companies.
Chapter Office Territorial subdivision within a Chapter.
Primary Chapter The one Chapter through which a company pays National dues. Every company has exactly one.
Chapter-Only Member A member company that pays National dues through a different chapter but belongs to this chapter (pays chapter/state dues only).
National-Paying Member A member company that pays National dues through this chapter. The most common type.
Dues Category Membership tier based on company type (contractor, associate, supplier) and revenue. Determines invoice amounts.
Dues Schedule Grouping of categories with dollar amounts for a year. A chapter can have multiple schedules in the same year.
National Category Numeric identifier (accepts decimals) that maps a chapter's category to ABC National's category structure. Used to lock National dues amounts.
Invoice Type Three types: New (N) for first-year members, Renewal (R) for subsequent years, Adjusted (A) for corrections/modifications.
Invoice Status Open (unpaid), Paid (payment received), or Dropped (member cancelled, invoice void).
Prorated Invoice A Year 2 invoice reduced to cover only the remaining months of the calendar year after Year 1 membership ends.
15-for-12 Program offering 15 months of membership for paying 12 months of dues. Eligible if member joined Oct/Nov/Dec.
FEA Free Enterprise Alliance — issue advocacy donations, optional additional line item on invoices.
TCEF / Trimmer Trimmer Construction Education Foundation — education donations, optional additional line item on invoices.
PAC Political Action Committee — political contributions, optional additional line item on invoices.
Preference Set Named grouping of memos, discounts, and additional line items created during batch invoicing for reuse across batch runs.
Discount-If-Paid-By Early-payment incentive with fixed date range (e.g., 10% off if paid by Nov 15). Can be flat $ or percentage.
Dues Report Transition Date National setting (e.g., the 20th of each month) controlling which month defaults on the Monthly Dues screen.
SPM Schedule of Paid Members — counts New and Renewal invoices only (excludes Adjusted). Used for financial reporting.
Wells Fargo (WF) Payment processor through which chapters remit National dues and contributions to ABC National monthly.
XREF Cross-reference linking a chapter-only member to their national-paying chapter. Validated at payment time.
Bridge File Monthly data file from third-party AMS vendors, used by non-CHAD2 chapters to import member/invoice data.
Load File Monthly data file from legacy CHAD, used by non-CHAD2 chapters to import member/invoice data.
CHAD Legacy AMS (Access-based system), predecessor to CHAD2.
CHAD2 New web-based AMS currently being built, replacing CHAD.
Billing ID System ID for additional line items (FEA, TCEF, PAC, custom items).
Member Portal Admin (Level 3) Contact within a member company authorized to view and pay invoices in the member portal.
No-Login Payment Link Invoice-specific URL included in email that members can click to pay without portal login (includes reCAPTCHA and lockout).
Life Member Individual afforded lifetime ABC membership in recognition of substantial contribution. Tracked separately from company members.
Processing Queue National Staff's dashboard showing all chapters' monthly submissions sorted by status (Open, Submitted, Under Review, Approved, Published).
Line Alert Status Audit result flag on monthly invoices: OK (pass all audits), Information (minor issue), Warning (possible issue), Error (likely issue).

Testing Strategy & Priorities

High-level approach, critical workflows, and regression focus areas

Testing Approach & Priority Areas

Core Testing Pillars: The ABC Membership & Dues module involves complex financial calculations, membership lifecycle states, and multi-party workflows. Testing must verify both business rules and edge cases.

  • Priority 1 (Critical): Dues Year Setup, Batch Invoicing audits, Invoice payment flows, Wells Fargo integration, Month-end submission and National reporting
  • Priority 2 (High): Proration formulas, 15-for-12 program, Portal payment flows, Invoice Rule creation and validation, Preference Sets (Step 2)
  • Priority 3 (Medium): Edge cases (chapter-only XREF, duplicate invoices, adjusted invoices), Special scenarios (start-up contractor removal), Monthly dues transitions
  • Test Data Requirements: Multiple chapters, diverse member types (National, Chapter-Only, Life), various dues categories and schedules, mix of new/renewal/adjusted invoices
  • Environment Setup: Pre-load reference data (chapters, categories, schedules, discounts). Create baseline invoices for month-end scenarios.
Regression Testing Checkpoints

Key Workflows to Verify on Every Release:

  • Dues Year creation with categories, schedules, discounts, and memos
  • Batch invoicing with all 12 audits passing (6 member + 5 invoice + 1 email)
  • Invoice creation, editing, deletion for both new and renewal members
  • Partial pay vs. full pay, 15-for-12 program eligibility and $0 invoices
  • Proration formula: Total = (Dues/12) × (12 - month_joined + 1), Credit = Original - Total
  • Portal login (with/without reCAPTCHA), payment gateway capture, already-paid states
  • Chapter monthly submission to National with validation audits
  • Month-closed restrictions (paid invoices cannot modify if month closed and reported)
  • Start-Up Contractor REMOVAL verification (ABC-2181): ensure no active references remain
  • Email merge system integration (Line #60 audit check)
Data & Environment Baseline

Required Test Data Setup:

  • Chapters: 3+ chapters including CHAD2 and non-CHAD2 variants; at least one with state dues enabled
  • Members: National-paying, Chapter-only, Life members; joined in different months (early, late, Oct-Dec for 15-for-12)
  • Dues Schedules: Multiple categories with varying rates; discount settings (amount, percent, date-based)
  • Preference Sets: At least one saved in Batch Invoicing Step 2 with memos, discounts, and additional lines (minimum 1 parameter)
  • Invoice States: Open, Paid, Partial-Pay, Dropped, Adjusted; spanning multiple years
  • Portal Setup: Payment gateway configured (test credentials), reCAPTCHA enabled for at least one test scenario
  • Wells Fargo: Test account configured for publish/reconcile cycles

Invoice Rules & Management

Validation testing, create/edit/delete rules, type restrictions, and category changes

Invoice Rule Lifecycle AMENDED · ABC-2078

What to Test: Rules enforce business logic on invoices (e.g., "if joined in Oct-Dec, apply 15-for-12 flag"). Full CRUD operations and validation.

  • Create Rule: Define rule name, condition (e.g., month joined = October), action (e.g., apply 15-for-12 flag). Verify system accepts rule.
  • Create Rule: Test invalid conditions (e.g., nonsense values); verify system rejects with helpful error.
  • Edit Rule: Change condition or action; verify changes apply only to new invoices, not retroactive.
  • Edit Rule: Disable rule without deleting; verify disabled rule no longer triggers.
  • Delete Rule: Verify system prevents deletion if active invoices reference it (or handles gracefully).
  • Rule Ordering: Create 2+ rules with overlapping conditions; verify order of evaluation and conflict resolution.
  • Rule Testing: Before activation, test rule on sample invoice data; verify logic is correct.
Test Scenario
Create rule: "If member joined in November, apply 15-for-12 and create $0 renewal Year 2". Test on batch of 10 October members (should NOT trigger) and 10 November members (SHOULD trigger with 15-for-12 flag and $0 invoice). Verify rule triggers correctly. Then edit rule to exclude members with adjusted invoices. Test again. Disable rule and test (should NOT trigger). Finally, delete rule (should be allowed since no active invoices depend on it).
Invoice Type Restrictions AMENDED · ABC-2879

What to Test: Invoice types (New, Renewal, Adjusted) have business rules and restrictions.

  • New (N): First invoice for member. System should not allow creation if member already has invoice for that year.
  • Renewal (R): Subsequent years. System should not allow if prior year unpaid (unless special rule like partial pay).
  • Adjusted (A): Modify existing invoice (amount, due date, etc.). Can only adjust if prior invoice exists.
  • Test type transitions: N → R is normal. N → A if member moves category mid-year. R → A if corrections needed.
  • Test edge case: Create N invoice, then immediately create A invoice. Verify order and totals.
  • Test edge case: Create R invoice when no prior year invoice exists (system should reject or auto-create N first).
  • Test edge case: Create A invoice when no base invoice exists (system should reject).
Regression Checkpoint
Create member, generate N invoice for $1000. Test: Can user create another N invoice? (Should reject - only one per year). Can user create R invoice before paying N? (Depends on rule - test both scenarios). Can user create A invoice to reduce N from $1000 to $900? (Should allow, create adjusted credit of $100).
Category Changes & Invoice Impact AMENDED · ABC-2598

What to Test: When member's dues category changes mid-year, test invoice recalculation and adjustment workflow.

  • Category Change: Member moves from Category A ($1000) to Category B ($1500) mid-year. Create adjusted invoice with difference ($500 additional).
  • Category Change: Reverse scenario (B → A). Create adjusted invoice with credit ($500).
  • Category Change: Test on already-paid invoice. If month closed and reported, system should block edit (see Month-Closed Restrictions).
  • Category Change: Test on partial-pay invoice. Adjust total due after partial payment; verify balance calculation.
  • Category Change: System automatically creates adjusted invoice or requires manual entry; verify correct behavior.
Test Scenario
January 1: Create invoice for member in Category A ($1200). January 15: Member upgrades to Category B ($1500). System should offer to create adjustment invoice for $300. Verify original invoice shows $1200, adjustment shows +$300, total due = $1500. If member paid $800 in January, test partial pay logic with adjustment.
Paid Invoice Editability JIRA ONLY · ABC-2578

What to Test: Paid invoices ARE editable (ABC-2578), with restrictions based on month-closed status and reporting state.

  • Paid Invoice Edit (Month Open): Member's paid invoice from January (month still open, not reported). User should be able to edit amount, due date, notes. Create adjusted invoice for any changes.
  • Paid Invoice Edit (Month Closed, Not Reported): Paid invoice from February (month closed but not yet submitted to National). Verify edit allowed (adjustment created).
  • Paid Invoice Edit (Month Closed, Reported): Paid invoice from March (month closed AND reported to National). Edit should be blocked or require special permission. Test system behavior (reject, warn, allow with audit trail).
  • Partial-Paid Invoice Edit: Invoice with $500 original, $200 paid, $300 remaining. User edits total to $700. Verify balance recalculated ($500 paid).
  • Test concurrent edit: Two users edit same paid invoice simultaneously; verify last-write-wins or conflict resolution.
Critical Regression
Create invoice Jan 1, pay full amount Jan 15, close January month Mar 1, report to National Mar 5. Try to edit paid invoice. System should block with message: "Cannot modify - month closed and reported to National". Request special edit. Admin allows it. Verify audit trail logs edit request, approval, and any adjusted invoice created.

Scenario Thinking

Cross-functional scenarios and what-if analysis for comprehensive testing.

Dues Year Setup Testing

Category creation, schedules, discounts, memos, and copy-from-year workflows

Category & Schedule Configuration

What to Test: Dues categories define membership tiers (by company type/revenue). Schedules group categories and set dollar amounts per year.

  • Create category with valid National Category numeric mapping (accepts decimals per ABC spec)
  • Create schedule with multiple categories; verify all categories appear in invoicing dropdowns
  • Edit category after schedule is active; verify changes do NOT apply retroactively to existing invoices (only new invoices)
  • Delete unused category; verify system prevents deletion if invoices reference it
  • Verify category names display correctly on invoice, portal, and reports
  • Test edge case: category with $0 dues (if applicable)
  • Test edge case: decimal amounts in category rates (e.g., $1,234.56)
Key Regression Checkpoint
After editing a category, create a new invoice using that category and verify the updated rate is applied. Then create an invoice using the old schedule year and confirm it retains the old rate.
Discount & Memo Management

What to Test: Discounts reduce invoice amounts; memos add narrative/tracking. Both can be applied at schedule level or per-invoice.

  • Create discount with amount (fixed dollar) and percent (percentage); verify correct calculation on invoice
  • Apply discount with date range (e.g., "if paid by Dec 31"); verify system uses actual date ranges not days from invoice date
  • Create memo with WYSIWYG formatting; verify memo appears on invoice and Chapter reports when selected in Batch Invoicing Step 2
  • Edit discount after invoices created; verify old invoices retain original discount (no retroactive changes)
  • Test edge case: multiple discounts on single invoice (stacking)
  • Test edge case: discount amount exceeds invoice total (potential $0 or negative invoice)
  • Test edge case: discount date range that has already passed at invoice creation time
  • Verify discount does NOT apply to Chapter-only members (if configured)
Edge Case: Discount-If-Paid-By
Create invoice on Jan 1 with "discount if paid by Jan 31". Member pays on Jan 30 (qualifies) and again on Feb 5 (outside window). Verify only the Jan 30 payment applies discount. Test with different fiscal calendars (mid-month discounts).
Additional Line Items (FEA, TCEF, PAC)

What to Test: Additional line items are per-year configuration items (FEA, TCEF, PAC, chapter-defined) that appear on invoices alongside dues amounts.

  • Create additional line item with flat $ amount; verify it appears on invoice totals
  • Create additional line item with % amount (by total or by category); verify correct calculation
  • Verify new line items default to Active status (not Inactive)
  • Verify Type field is editable after creation
  • Verify browse screen shows % for percentage-type and $ for dollar-type items
  • Flag line items for inclusion/exclusion on: new invoices, renewal invoices, adjusted invoices
  • Test Voluntary Contributions: Opt-in vs Opt-out control on portal
  • Verify some names are nationally controlled (chapter can't rename); others are chapter-defined
  • Test "Copy from Previous Year" when year has no items
Note
Line items configured here become available for selection in Batch Invoicing Step 2 and can be bundled into Preference Sets (Step 2 feature) alongside memos and discounts.
Copy-From-Year Workflow AMENDED · ABC-2057

What to Test: Copy settings (categories, schedules, discounts) from prior year to new year to speed setup.

  • Copy entire schedule from prior year; verify all categories, amounts, discounts copied exactly
  • Modify copied schedule (e.g., increase rates 5%); verify changes apply only to new year, not source year
  • Copy partial settings (only certain categories); verify unchecked items not copied
  • Test copy when prior year has no invoices yet (edge case)
  • Test copy when prior year is locked/closed (edge case)
  • Verify audit trail shows copy operation with source/target years
Test Scenario
Year 2025 has 3 categories at $500, $750, $1000 with 5% early-pay discount. Copy to Year 2026. Edit 2026 to $550, $825, $1100. Create invoices in both years. Verify 2025 invoices use original amounts, 2026 uses new amounts. Confirm discount applies to both.

Batch Invoicing & Audits

12 total audits (6 member, 5 invoice, 1 email merge), Step 1-3 validation, and preference sets

Audit 1-6: Member Validation AMENDED · ABC-2166

What to Test: Six member-level audits validate membership configuration before invoicing.

  • Audit 1: Invalid National Categories — Member has National Category mapping outside accepted range. Create member with invalid National Category value; run batch; verify audit flags and user can manually correct or skip.
  • Audit 2: Invalid Chapter-Only XREF — Chapter-only member missing or has invalid cross-reference to National-paying chapter. Create chapter-only member without XREF; verify audit blocks invoicing and suggests remediation.
  • Audit 3: National Member Category Issue — National-paying member category mismatched or undefined. Verify audit catches and proposes fix.
  • Audit 4: Mismatched Schedule/Category — Member category not found in selected schedule. Test with deleted category or wrong schedule selection.
  • Audit 5: Fix Start-Up ContractorREMOVED feature (ABC-2181). Verify no references to Start-Up Contractor remain in batch audits. If legacy data exists, ensure system gracefully handles it (no errors, no invoices generated with removed feature).
  • Audit 6: Start-Up Contractor ReviewREMOVED feature (ABC-2181). Verify removed. Test that any historical invoices marked as start-up do not re-trigger this audit.
Critical Regression
Run batch with mix of valid and invalid members. Verify system correctly flags all 6 audit types. User resolves Audits 1-4, skips Audits 5-6 (since removed). Batch proceeds and creates invoices only for valid members. Audit trail records all actions.
Audit 7-11: Invoice Validation

What to Test: Five invoice-level audits validate amounts, payment status, and duplication.

  • Audit 7: Not-Invoiced-Yet — Member has no invoices for this period/year. Verify audit allows invoice creation (should pass).
  • Audit 8: Not Paid/Processed 15-for-12 — Member eligible for 15-for-12 (joined Oct-Dec) but prior 15-for-12 invoice not yet paid/processed. Verify audit flags; user can retry or override if needed.
  • Audit 9: Joined in Prior Year Prorates — Member joined in previous year; renewal invoice should be prorated. Formula: Total = (Dues/12) × (12 - month_joined + 1), Credit = Original - Total. Create member, run batch year 2, verify prorated amount and credit applied correctly.
  • Audit 10: Adjusted Invoices — Previous adjustment exists; new invoice may conflict. Verify audit flags duplicates/conflicts and allows user to merge or create separate.
  • Audit 11: Duplicate Invoices — Invoice already exists for this member/period. Verify audit prevents creation; user must delete prior invoice or change period.
Test Scenario: Proration (Audit 9)
Member joins Aug 2025 (Year 1: full 12 months through July 2026). Year 2026 renewal should prorate for 5 remaining months (Aug-Dec = 5). If annual dues = $1200: Total = ($1200/12) × 5 = $500, Credit = $1200 - $500 = $700. Create invoice and verify amounts.
Audit 12: Email Merge System Integration AMENDED · ABC-2767

What to Test: System validates email addresses for merge/notification (Line #60 audit check).

  • Verify member/chapter contact has valid email address before batch creation
  • If email missing or invalid, audit flags for manual entry or skip
  • Test with multiple email formats (user@domain.com, user+tag@domain.co.uk, etc.)
  • Verify emails used for invoice notifications are correctly populated
  • Test batch with all members missing email; verify audit count = batch size
  • Test batch with some members missing email; verify only flagged members blocked
Regression Checkpoint
Run batch invoicing. System detects 3 members with missing email. User adds emails for 2 members, overrides the 3rd (marked "do not notify"). Batch proceeds with 2 members eligible for email notification, 1 marked as manual follow-up. Verify audit log and notification queue.
Step 2: Preference Sets (Bundles of Memos, Discounts, Line Items)

What to Test: Preference Sets are created and managed in Batch Invoicing Step 2. They bundle memos, discounts, and additional line items (all configured separately in Dues Year Setup) for convenient reuse across batch runs.

  • Create Preference Set with at least 1 parameter (memo, discount, or additional line) — minimum 1 required
  • Save Preference Set with a name; verify it appears in "Select Preference Set" dropdown
  • Select a saved Preference Set; verify all bundled settings (memos, discounts, line items) are restored
  • Delete a Preference Set; verify it's removed from the dropdown
  • Try saving a Preference Set with 0 components — system should reject or warn
  • Apply Preference Set during batch invoicing; verify all bundled items appear on generated invoices
  • Edit Preference Set after invoices created; verify changes only apply to future batch runs (old invoices retain original settings)
  • Create Preference Set with conflicting discounts (e.g., two percent discounts); verify resolution logic
Key Distinction
Memos, discounts, and additional line items are created in Dues Year Setup. Preference Sets are created in Batch Invoicing Step 2 to bundle those items together for reuse. A Preference Set is a named shortcut — it selects specific memos, discounts, and line items that were already configured in the setup screens.
Regression Checkpoint
Create a Preference Set with memo, discount, and FEA line. Apply to 5 batch invoices. Verify all 5 invoices show the memo text, discount deduction, and FEA total. Then edit the Preference Set and create a new batch; old invoices retain original settings, new invoices get updated configuration.
Batch Steps 1-3 Edge Cases AMENDED · ABC-2780

What to Test: Batch invoicing has 3 main steps: Select Members → Select Schedule/Discounts → Preview & Confirm. Edge cases at each step.

  • Step 1 Edge Cases: Select 0 members (should warn), select 1 member, select all members. Test with filters (chapter, member type, dues status).
  • Step 1 Edge Cases: Re-running batch after partial completion (member already invoiced); verify system skips or warns.
  • Step 2 Edge Cases: Change schedule mid-batch (one group uses Sched A, another Sched B); verify consistent application or forces single schedule.
  • Step 2 Edge Cases: Apply Preference Set that creates conflicts (two discounts, duplicate memos); verify resolution logic.
  • Step 3 Edge Cases: Preview shows 1000+ invoices; verify pagination and performance. Export preview to CSV for manual review.
  • Step 3 Edge Cases: User edits individual invoice totals in preview; verify changes persist or are rejected. Test with invoice amount override.
  • Step 3 Edge Cases: Confirm batch with no invoices selected (all unchecked); verify warning or auto-select.
Test Scenario
Batch run for 100 members. Step 1: user selects all. Step 2: user applies Preference Set with 10% discount. Step 3: preview shows 100 invoices. User unchecks 3 members (already invoiced elsewhere). User clicks "Adjust totals" and manually increases 1 invoice by $50. Confirm batch. Verify 97 invoices created with discount, 1 invoice with manual override, 3 skipped, audit trail complete.

Regression Checklists

Organized regression testing coverage by feature area.

Portal Testing

No-login access, reCAPTCHA, payment gateway, already-paid scenarios, and member dashboard

Portal Access & Authentication AMENDED · ABC-2607

What to Test: Portal allows members to pay without CHAD login (no-login flow) and with optional reCAPTCHA verification.

  • No-Login Access: Portal link shared with member (via email, invoice). Member clicks link, arrives at payment page. NO username/password required.
  • No-Login Link Generation: Chapter staff generates no-login link for invoice. Link contains encrypted token unique to invoice. Test link expiration (if applicable).
  • No-Login Link Validation: Link is valid for correct invoice. Invalid/expired link shows error. Test modified link (tampered token).
  • reCAPTCHA (if enabled): Portal presents reCAPTCHA challenge before payment. Test with reCAPTCHA enabled and disabled.
  • reCAPTCHA Validation: Member completes reCAPTCHA, system verifies with Google. Test with valid and invalid reCAPTCHA responses.
  • Session Management: Member accesses portal, takes 1 hour to fill out form. Session times out. System prompts re-login (no-login restart) or shows error.
  • Multiple Invoices: Member has 3 unpaid invoices. Portal shows list of all 3. Member can select which to pay or pay all.
Test Scenario
1. Chapter generates no-login link for Invoice #1234. 2. Link emailed to member. 3. Member clicks link (no CHAD login needed). 4. Portal shows invoice details and payment form. 5. If reCAPTCHA enabled: member completes challenge. 6. Member enters card and amount. 7. Payment processed. 8. Confirmation page shown. 9. Test: Modify link token; system rejects. 10. Test: Wait 24h (if link expires), re-click link; system shows expired message.
Portal Payment Rules & Restrictions AMENDED · ABC-2602

What to Test: Portal has specific payment rules (full pay only, no partial, no multi-invoice).

  • Full Payment Required: Invoice $2000. Portal allows payment of exactly $2000 (full). Rejects $500 (partial) or $2500 (over).
  • No Partial Pay via Portal: Unlike staff offline payments, Portal does NOT allow partial installments. Each payment must be full invoice amount.
  • Multiple Invoice Payment: Member has 2 invoices ($1000 each). Portal shows both. Member tries to pay both at once ($2000 total). Test: System accepts (combined payment) or rejects (one at a time only).
  • Already-Paid Invoice: Invoice marked "Paid" in system. Member clicks old payment link. System shows "Already Paid" and prevents duplicate payment.
  • Expired Invoice: Invoice due date passed and past grace period. Portal shows overdue status. Test: Can member still pay? (Usually yes, but flag as late.)
  • Dropped Invoice: Invoice status = "Dropped" (no longer owed). Portal link should be invalid or show "Invoice Cancelled".
Regression Checkpoint
Invoice $2000 created Jan 1. Portal link sent to member. Jan 5: Member logs in, tries to pay $500 (should reject: "Full payment required"). Member tries again with full $2000 (should accept). System processes payment, shows "Thank you" page. Next day: Member clicks old portal link again. System shows "Already Paid" and blocks duplicate payment.
Portal Tabs & Navigation AMENDED · ABC-2725

What to Test: Portal may have multiple tabs (Invoices, History, Profile, etc.) for member self-service.

  • Invoices Tab: Shows unpaid invoices with due dates, amounts, "Pay Now" button.
  • History Tab: Shows paid invoices with payment dates, amounts, receipts (downloadable).
  • Profile Tab: Shows member name, company, contact info. May allow editing (test if read-only or editable).
  • Tab Navigation: Member switches between tabs. Verify state persists (e.g., filters, selections).
  • Responsive Design: Portal works on desktop, tablet, mobile. Test payment flow on small screens.
  • Download Receipts: Member clicks "Download" on paid invoice. System generates PDF receipt with all details.
  • Print Invoice: Member clicks "Print" on unpaid invoice. Browser print dialog opens; PDF prints correctly.
Test Scenario
1. Member logs into portal. 2. Invoices tab shows 2 unpaid ($500, $1200) and 3 paid ($800, $600, $400). 3. Member clicks "History" tab. 4. Paid invoices load. Member clicks "Download" on $800 receipt. PDF downloads with invoice number, date, amount, payment date, method. 5. Member returns to Invoices tab. 2 unpaid still visible. 6. On mobile (375px width), test same flow - buttons stack, text readable, payment form adapts.
Member Dashboard & Notifications AMENDED · ABC-2370

What to Test: Portal may include member dashboard with summary data and notification settings.

  • Dashboard Summary: Shows total amount due, number of unpaid invoices, next due date, membership status.
  • Payment Summary: Year-to-date paid, current balance, last payment date.
  • Email Notifications: Member can enable/disable invoice emails, payment reminders, etc.
  • Notification Frequency: Test options (weekly, monthly, on-invoice-creation).
  • SMS Notifications (if supported): Test SMS delivery of payment links and reminders.
  • Notification History: Portal logs all notifications sent to member (for audit).
  • Opt-Out Handling: Member opts out of email. System should not send unless member re-opts in.
Test Scenario
Member logs in. Dashboard shows: "Total Due: $2000, 2 unpaid invoices, Next Due: Jan 31". Member clicks Settings. Disables email notifications. Creates new invoice. System respects opt-out (no email sent). Member re-enables notifications in settings. Next invoice triggered (creates new invoice). System sends email notification.

Monthly Dues Process & National Reporting

Chapter submission, National queue, status transitions, month-closed restrictions, and versioning

Chapter Monthly Submission Workflow AMENDED · ABC-2176

What to Test: Chapters submit monthly dues (invoices/payments) to National. Workflow: Chapter Reviews → Submits → National Reviews → Approves → Publishes.

  • Chapter Screen: Shows paid invoices for selected month/year, Dues Month Chapter Status (Open/Submitted/Under Review/Approved), tables with invoice details and totals.
  • Submit to National: Chapter clicks "Submit" button. System runs submission audits (Invalid Invoice Year, Invalid Member Type, Invalid New Member, Invalid Renew Member, Invalid Category, Non-Paying National Member, Invalid Chapter Only). If errors, present audit results; user can remedy and resubmit. If no errors, success message and report posted to National.
  • Submission Confirmation: System shows confirmation: "XX invoices submitted, totals: National $XXX, Chapter $XXX, etc."
  • Resubmission: User can resubmit after fixing errors. Each resubmission increments version number. System maintains version history.
  • Chapter Status Display: Screen updates to show "Submitted" status. Submit button disabled; only "Recall" or "Resubmit" available (depending on system design).
  • National Sign-Off (Not Required): Button available but optional. National can proceed without sign-off.
Test Scenario
Chapter finishes collecting Jan payments. Staff reviews Monthly Dues screen - shows 50 paid invoices, $50,000 total. Clicks "Submit to National". System runs audits; flags 2 invalid categories. Staff corrects and resubmits. System shows v2 submission. No errors. Success message: "50 invoices submitted". National receives notification and can review queue.
National Processing Queue & Status Transitions AMENDED · ABC-2842

What to Test: National staff review chapters' submissions in queue, update status, and publish to Wells Fargo.

  • Queue View: Defaults to previous month/year. Shows dashboard with counts: Open, Submitted, Under Review, Approved, Published. Table with chapters, status, date submitted, late indicators, notes field, contact email.
  • Status Transitions: Open → Submitted (chapter action) → Under Review (National action) → Approved (National action) → Published (National action, triggers Wells Fargo publish).
  • Update Status Button: National selects chapter, clicks "Update Status", chooses next status. If updating to "Approved", system auto-triggers sign-off request email to chapter contact.
  • Add/Edit Notes: National can add notes per month (notes don't carry over to next month). Test note entry, editing, and display.
  • Exclude Invoices Modal: National can select specific member invoices to exclude from processing (e.g., disputed, incomplete data). Excluded invoices NOT sent to Wells Fargo. Test selection and verify excluded count.
  • Publish to Wells Fargo: National selects chapters to publish. System warns if already published for that month. Publish creates Wells Fargo file and transmits (or queues for transmission).
  • Copy Contact Emails: National can copy all contact emails from visible chapters (for bulk communication).
Critical Test Flow
1. Jan submissions queued: 10 chapters submitted. Dashboard shows counts. 2. National staff reviews Chapter A. Clicks "Update Status" → "Under Review". 3. Reviews Chapter B. Clicks "Update Status" → "Approved". System auto-sends sign-off request email to Chapter B contact. 4. National reviews all 10. Selects 9 to publish (excludes 1 pending dispute). Clicks "Publish to WF". System creates WF file for 9 chapters. 5. Verify audit trail logs all status changes, publish timestamp, excluded chapter reason.
Month-Closed Restrictions & Reporting AMENDED · ABC-2867

What to Test: Once a month is closed and reported to National, paid invoices cannot be modified without special permission.

  • Month Status Tracking: System tracks each month's status: Open (can edit/add invoices), Closed (locked for changes), Closed + Reported (extra restriction on paid invoice edits).
  • Close Month Workflow: Chapter or National closes month (manual action or automatic after submission).
  • Closed Month Indication: Chapter monthly screen shows month as locked/closed. Users warned they cannot modify invoices.
  • Paid Invoice Edit (Month Closed, Not Reported): Staff attempts to edit paid invoice from closed month that is NOT yet reported. System should allow (or warn but allow) because data can still be corrected before reporting.
  • Paid Invoice Edit (Month Closed, Reported): Staff attempts to edit paid invoice from month that is closed AND reported to National. System blocks with message: "Cannot modify - month closed and reported. Request approval from National."
  • Adjustment Invoice for Closed Month: As alternative to editing, staff can create Adjusted invoice. Test if Adjusted invoices can be created for closed months (usually yes).
  • Reported Month Indicator: System clearly marks month as "Reported to National" (e.g., date published, WF confirmation).
Test Scenario
Jan invoices collected and submitted. Feb 1: National closes & reports Jan. Feb 2: Chapter staff tries to edit paid Jan invoice (reduce amount to $900 from $1000). System blocks: "Cannot modify - month closed and reported". Staff instead creates Adjusted invoice (-$100 credit) for Jan to achieve same result. System allows. Audit trail shows original invoice unchanged, but adjustment recorded.
Versioning & Resubmission History AMENDED · ABC-2640

What to Test: System maintains version history of submissions (useful for troubleshooting and audit).

  • Version Numbering: First submission = v1, resubmission after fixes = v2, etc. System tracks version in database.
  • Version History View: National staff can view history of all submissions for a chapter/month. Each version shows submission date, invoice count, totals.
  • Version Content: Staff can drill into version to see which invoices were included in that submission (useful to compare v1 vs v2).
  • Revert to Version: (If supported) National can revert to prior version (e.g., "v2 had an error, go back to v1").
  • Version Timestamp: Each version logged with exact submission date/time and submitting user.
  • Archive/History Retention: Old versions retained indefinitely (or per policy). Test that versions don't get deleted when month is closed.
Test Scenario
Chapter submits Jan 20 (v1): 50 invoices. National reviews, finds error. Chapter resubmits Jan 25 (v2): 50 invoices (corrected). National reviews, approves. Later, National checks version history: shows v1 (20-Jan, error noted) and v2 (25-Jan, approved). National can click either version to see content and confirm differences.

Integration Points & Cross-Module Dependencies

Wells Fargo, email system, company profiles, and module dependencies

Wells Fargo Integration JIRA ONLY · ABC-1601

What to Test: Wells Fargo (WF) is payment processor for Chapter-to-National remittances. System publishes invoices to WF, reconciles payments.

  • WF Credentials & Configuration: Test WF credentials configured in system (API key, merchant ID, etc.). Test connection to WF (ping test).
  • Publish to Wells Fargo: National staff publishes approved chapters' invoices to WF. System creates WF batch file (CSV, XML, or API call) with invoice details: member name, invoice amount, invoice number, due date.
  • Publish Confirmation: System shows confirmation: "Published 50 invoices to WF, Batch ID #12345". Timestamp and file hash recorded for audit.
  • Already Published: If month/chapter already published, system warns: "Jan invoices for Chapter A already published on 1/20. Publish again?" (allows overwrite or cancels).
  • WF Payment Reconciliation: Chapter members pay via WF portal. WF reports payments back to CHAD2 (nightly feed or manual import).
  • Reconciliation Audit: System matches WF payment reports to CHAD2 invoices. Unmatched payments flagged for manual review. Test audit report (SPM Dollars vs ABC Load File).
  • Payment Status Sync: When WF payment received, system updates invoice status to "Paid" (or records partial payment). Test payment sync delay (may be delayed 1-2 days).
  • Disputed Charge Handling: Test member chargebacks or disputes on payment. System notifies chapter/national of dispute.
Critical Integration Test
1. Create 5 invoices for Chapter A (total $5000). 2. National publishes to WF. 3. System creates WF batch with 5 invoices. Verify batch file format (CSV headers: member, amount, invoice#, due date). 4. Simulate WF payment: Member pays $1000. 5. WF feeds back payment report. 6. System reconciles: finds $1000 payment, matches to Invoice#1. 7. System updates Invoice#1 status to "Paid", amount paid $1000. 8. Verify SPM Dollars report shows payment received and reconciled.
Email System Integration JIRA ONLY · ABC-1602

What to Test: System sends emails for invoices, payment reminders, notifications, and reports.

  • Invoice Email: New invoice created; system sends email to member contact with invoice details, due date, payment link (if portal enabled).
  • Email Template: System uses templated email (editable by admin). Test template variables (member name, invoice #, amount, due date, chapter name) render correctly.
  • Payment Reminder Email: Invoice past due; system sends reminder email (automated, scheduled, or triggered manually).
  • Payment Confirmation Email: Member pays (online or staff records offline); system sends confirmation with transaction details.
  • Sign-Off Request Email: National approves chapter submission; system auto-sends sign-off request email to chapter contact (per ABC-2842).
  • Email Delivery Tracking: System logs email sent (recipient, timestamp, subject, template used). Test delivery and bounce handling.
  • Email Opt-Out: Member opts out of email notifications. System respects and does not send unless critical (e.g., payment received).
  • Email Merge Feature: Chapter can manually merge emails with member list (e.g., export to Word Mail Merge). Test merge fields and export format.
  • Bulk Email Operations: National staff can email all chapter contacts for month (e.g., "Monthly Dues Summary"). Test copy-emails-to-clipboard feature.
Test Scenario
1. Create invoice $2000 for member@example.com. 2. System sends invoice email with: "Invoice #1234 for $2000 due 1/31. Pay Now: [portal-link]". 3. Member pays 50% online. 4. System sends confirmation email: "Payment received: $1000, Balance due: $1000". 5. Jan 31 passes, no payment for remaining $1000. 6. System sends reminder email: "Overdue reminder: $1000 due". 7. Test: Member opted out of reminders; system should not send #6. 8. Test email delivery log shows all 3 emails (invoice, payment, reminder) with timestamps and recipient.
Company Profile Integration JIRA ONLY · ABC-1662

What to Test: Dues module integrates with Company Profile module. Member company records have Dues History tab.

  • Dues History Tab: On company profile, "Dues History" tab shows all past dues (by year). Columns: Year, Status, Member Type, Category, Paid Date, National Amount, Chapter Amount, etc.
  • Dues History Accuracy: Verify data matches dues module (no discrepancies). Test with member having 5+ years of history.
  • Link to Full Invoice: From Dues History, user can click year to drill into full invoice details (amount, due date, items, payments).
  • Dues Status on Company Profile: Company profile header shows current dues status (e.g., "Active Member - Paid through 12/31/2026" or "Lapsed - last paid 12/31/2025").
  • Cross-Module Consistency: Changes in Dues module (e.g., drop member) immediately reflected in Company Profile (no lag).
  • Member Type Display: Company profile shows member type (National-paying, Chapter-only, Life). Test accuracy after changes.
Test Scenario
1. Open company profile for "ABC Corp". 2. Click "Dues History" tab. 3. Shows years 2022-2026: 2022 Paid $1200, 2023 Paid $1200, 2024 Paid $1200, 2025 Paid $1200, 2026 Open $1200. 4. Click on 2025. 5. Full invoice details show: invoice #5678, amount $1200, paid 12/15/2025. 6. Return to company profile header. Shows "Active Member - Current dues paid through 12/31/2025". 7. In Dues module, mark 2026 as Paid. 8. Return to company profile. Header updates to "Active Member - Current dues paid through 12/31/2026".
Member Engagement & Event Integration JIRA ONLY · ABC-1605

What to Test: Membership status impacts Event registration (members-only events, member pricing).

  • Member Verification: Event module queries dues module: Is this member "Paid" for current year? Returns yes/no.
  • Lapsed Member Block: If dues not paid, member cannot register for members-only event. Test rejection with helpful message.
  • Pricing Impact: Member pricing for events is lower than non-member. Dues module confirms member status for discounted pricing. Test pricing calculation.
  • Membership Status Cache: If cache lag (e.g., member pays invoice, status updates in dues module but event module cached old data), test cache invalidation (manual purge or TTL).
  • Life Member Handling: Life members should be perpetually "active". Test that event module recognizes and grants member benefits.
  • Chapter-Only Member Events: Chapter-only member registering for National event. Test: Can they register? Do they get member pricing? (May vary by business rule.)
Test Scenario
1. ABC Corp is paid member for 2026. 2. National event created: "Summit 2026" - members-only, member price $500, non-member price $999. 3. ABC Corp employee registers. System verifies ABC Corp is paid member. Registration allowed at $500. 4. Month later: ABC Corp's 2026 dues lapsed (payment deadline passed). 5. Another ABC Corp employee tries to register for different members-only event. System checks dues status: lapsed. Registration blocked: "Your company membership has expired. Contact chapter to renew." 6. Chapter renews membership. 7. Employee re-tries registration. Allowed at $500.
State Dues & Multi-Chapter Scenarios JIRA ONLY · ABC-1603

What to Test: Some states have state-level dues organizations. Companies may belong to multiple chapters with different state requirements.

  • State Dues Enabling: Chapter setting controls whether state dues are collected. Test with state dues on/off.
  • State Dues Calculation: If enabled, state dues added to invoice. Amount may be fixed or percentage. Test both.
  • State Dues Remittance: Chapter remits state dues separately to state organization (not National). Test reporting (Chapter sends State Report).
  • Multi-Chapter Member (Same State): Member belongs to Chapter A and Chapter B (both in State X). Invoice from Chapter A includes National + Chapter A + State X dues. Invoice from Chapter B includes Chapter B + State X dues (no National repeat). Test: Verify National dues appears only in Primary Chapter invoice.
  • Multi-Chapter Member (Different States): Member's Primary Chapter in State A, also belongs to Chapter in State B. Invoice A: National + Chapter A + State A. Invoice B: Chapter B + State B. Test invoices calculated correctly and payment/reporting handles both states.
  • Chapter-Only XREF: Test that Chapter-Only member with invalid XREF cannot pay invoices (blocked by Audit 2). Test XREF correction and re-invoicing.
Test Scenario
1. ABC Corp's Primary Chapter = Chapter-CA (California). 2. ABC Corp also belongs to Chapter-TX (Texas, Chapter-Only). 3. Batch invoicing Year 2026. 4. Invoice from Chapter-CA: National $1200 + Chapter-CA $400 + CA State $100 = $1700. 5. Invoice from Chapter-TX: Chapter-TX $300 + TX State $50 = $350 (no National because Chapter-Only). 6. ABC Corp pays both invoices. 7. Chapter-CA submits to National: $1200 National + $400 Chapter. State Dues Report: $100 CA State (to be remitted to CA state org). 8. Chapter-TX submits: $300 Chapter + $50 TX State (to be remitted to TX state org). 9. Verify reporting separates National, Chapter, and State amounts correctly for each chapter.
Non-CHAD2 Chapter Bridge & Load Files AMENDED · ABC-2489

What to Test: Non-CHAD2 chapters use Bridge files (3rd-party export) or Load files to import monthly dues data.

  • Bridge File Upload: Non-CHAD2 chapter uploads Bridge file (3rd-party vendor format). System parses, validates structure, maps to CHAD2 format.
  • Load File Upload: Non-CHAD2 chapter uploads Load file (legacy CHAD format). System parses and imports.
  • File Validation: System checks for structural errors (missing columns, invalid values). Reports errors to user (e.g., "Line 3: Invalid invoice amount").
  • Data Mapping: Bridge/Load data mapped to CHAD2 structure (ELTL → flat structure). Test data accuracy (member name, amount, due date).
  • Import Confirmation: After successful import, data follows same process as CHAD2 chapters (submit to National, etc.).
  • Manual Dues Report Upload: Non-CHAD2 chapter can upload Monthly Dues Report PDF (stored as-is, no parsing). Used for record-keeping.
  • Import Error Recovery: File has errors. User corrects 3rd-party data, re-uploads. System processes corrected file. Verify old import doesn't create duplicates.
Test Scenario
1. Non-CHAD2 Chapter X exports monthly data from their legacy AMS as Bridge CSV. 2. Chapter staff logs into CHAD2 Dues > Import. 3. Uploads Bridge file. 4. System parses: 50 invoices found. 5. Validates: 1 line has invalid amount (negative). Reports error. 6. User corrects in legacy system, exports new Bridge file. 7. Re-uploads corrected file. 8. System accepts: 50 invoices imported to CHAD2. 9. Chapter staff submits to National using imported data (same process as CHAD2). 10. Verify imported invoices have same audit trail and reporting as manually-entered invoices.